So you can actually encode in 11-13 with SVT-AV1 in the current code. You can pass -a preset=13 to avifenc, but I think the output would confuse people:
Encoding with codec 'svt' speed [6], color quality [60 (Medium)], alpha quality [100 (Lossless)], tileRowsLog2 [0], tileColsLog2 [0], 128 worker thread(s), please wait...

I think I like your first alternative approach.

So you can actually encode in 11-13 with SVT-AV1 in the current code. You can pass -a preset=13 to avifenc, but I think the output would confuse people

What about (also or instead) fixing stdout for this use case then? Because this PR does not prevent people from using -a preset=13 and have a confusing console output.

I'm not sure I want to do this as then we may need to establish precedence rules. E.g. if you specify preset and speed. For simplicity I think it is better this way.

I am a bit uneasy about changing the value of a define in a public header.
@wantehchang Is this common practice?

Vincent suggested just changing avifenc behavior, because the API currently allows for SVT speed 11+.

So what about keeping #define AVIF_SPEED_FASTEST 10 as is. Adding #define AVIF_SPEED_FASTEST_SVT-AV1 13 and changing avifenc to clamp the speed to AVIF_SPEED_FASTEST_SVT-AV1?

@FrankGalligan @y-guyon I am sorry I forgot to answer Yannis's question. I will take a look tomorrow.

But very quickly, this is very likely a gray area. That is, changing the value of AVIF_SPEED_FASTEST (a macro defined in a public header) is an incompatible change strictky speaking, but under a practical definition of backward compatibility, I suspect it won't break any application. But I need to think about this more.

I have two proposals that avoid changing AVIF_SPEED_FASTEST. I recommend the first proposal.

Proposal 1: Use avifEncoder::codecChoice to select which speed scale to use.

• AVIF_CODEC_CHOICE_AUTO (the default) selects the current libavif speed scale of 0..10. AVIF_SPEED_SLOWEST and AVIF_SPEED_FASTEST only apply in this mode.
• Any other AVIF_CODEC_CHOICE_* value selects the original speed scale of the explicitly chosen codec. This is a change of behavior.
• In the avifenc command line interface, the -c / --codec option selects which speed scale to use.

I think this proposal is easy to understand even though the link between codecChoice and speed may not be obvious at first. It does not require adding a new avifEncoder option, so I prefer this proposal.

Proposal 2: Add an avifBool useCodecSpeed option to avifEncoder.

• If useCodecSpeed is false (the default), use the current libavif speed scale of 0..10. AVIF_SPEED_SLOWEST and AVIF_SPEED_FASTEST only apply in this mode. This is the current behavior.
• If useCodecSpeed is true, use the original speed scale of the codec in use. This is new behavior.
• In the avifenc command line interface, useCodecSpeed is indicated by adding the codec: prefix to the value of the -s / --speed option. For example, -s 6 means speed 6 in the libavif 0..10 speed scale, and -s codec:6 means speed 6 in the original speed scale of the codec in use.

This proposal is fully backward compatible, but requires adding a new avifEncoder option.

Proposal 2 seems too complicated and do not think that is good to implement.

So for proposal 1 to get SVT-AV1 to encode with speed 13 you would need to set this command:
avifenc -c svt -s 13 temp.png temp.avif

And if you used this command, even with svt the only encoder:
avifenc -s 13 temp.png temp.avif

You would get speed 10 instead of 13.

How about proposal 3

• Keep AVIF_SPEED_FASTEST as is. I.e. 10
• Change codec_svt.c to clamp from 0 to 13.
• Change avifenc.c to remove the check for if (settings.speed > AVIF_SPEED_FASTEST) { settings.speed = AVIF_SPEED_FASTEST; }
• • The library specific clamps will still happen in their wrapper code.
• No other changes.

With proposal 3 you will get speed 13 with both of these commands:
avifenc -c svt -s 13 temp.png temp.avif

And if you used this command, even with svt the only encoder:
avifenc -s 13 temp.png temp.avif